1. Field of the Invention
The present invention relates to telecommunication networks, and more specifically to a method and apparatus for reliably continuing a secure connection when the address of a machine at one end of the connection changes.
2. Related Art
Secure connections are often used to attain various features such as confidentiality/privacy (preventing third parties from accessing/viewing the exchanged information), data integrity (the data sent by a sender is not tampered with, by third parties), and authentication (the data is sent by the party purporting to be the sender), as is well known in the relevant arts.
A security association (SA) is generally associated with each secure connection. A SA generally contains several parameters which define the security services offered to a secure connection. SA is described in further detail with reference to examples in RFC 2401, available from www.ietf.org. In the embodiments described below, SA is used to specify the authentication mechanism (e.g. usage of digital certificates from a specific certificate authority or passwords, cryptographic algorithm etc.) and the traffic encryption services (e.g. payload encapsulation or header authentication, etc.).
SA is generally bound to a machine address (e.g., IP address) of another end. Typically, protocols such as Internet Security Association and Key Management Protocol (ISAKMP, described in RFC 2408) provide for creation of an SA for a secure connection, which is then used for secure exchanges on the connection. Each end machine uses an IP address of the other end machine in associating the SA to the specific secure connection.
The address of a machine at one end of the secure connection may change. For example, the IP address of a mobile node (e.g., a laptop machine) may change when the node moves from one sub_net (access network) to the other (in which common addresses would not be usable) as is well known in the relevant arts. It is often desirable that connectivity for user applications (operating on top of the secure connection) be continued seamlessly (with minimal disruption) when the address of a machine at one of the secure connection changes.
In one prior approach, the secure connection and the associated SA are set up afresh when the address of a machine at one end changes. Once the connection and the SA are set up, connectivity is continued for the user applications. In general, applications encounter disruption in connectivity while the secure connection and the SA are being set up.
Such a situation is undesirable generally when the users experience the disruption. The disruption may be experienced at least in situations when connectivity is absent for a few seconds. Such extended absence of connectivity can be encountered in situations where computationally intensive tasks may need to be repeated while negotiating various SA attributes.
For example, a substantial amount of processing resources may be required to generate keys corresponding to a machine at one end of the secure connection, and accordingly the users may experience the disruption. The disruption may be particularly more with devices (such as notebooks, handheld personal digital assistant, etc.) having limited computational resources. In addition, it may be desirable to minimize/avoid the data transfer overhead resulting from the need to negotiate various SA attributes.
At least some of such requirements appear to be addressed by the teachings of a document entitled, “Address Management for IKE version 2”, by Francis Dupont, Internet Engineering Task Force, publication date: January 2003 (hereafter “Dupont”). Specifically, in section “2.4 Mobility requirements” of Dupont, it is stated that, “When the mobile node moves, another care_of address is used and some SAs, including the IKE SA, must be updated to use the new address.” Section “3.5 Explicit address update” of Dupont further states that “The explicit mechanism MUST be used. A new notification has to be defined. We propose to copy it from the delete notification.” Delete notification is defined in RFC 2408 as well as in Annex C of a revised version of the above document with same title published in June 2003. The format specified there does not appear to include a provision for including the new machine (IP) address of the end machine (moving to a new location). It appears that the other end machine would learn the new IP address from the header (source IP address) of the explicit address update packet.
Several problems may be presented by such an approach. For example, an unknown third machine may snoop the explicit address update packet and “replay” with a different source IP address. Replay generally entails using the payload of the explicit address update packet noted above and resending the same payload in another packet. The machine at the other end of the connection may accept the address update and start communicating with the unknown third machine (instead of the machine that has moved with a new IP address). That is, the packets intended for the moving end machine may thereafter be diverted to the unknown third machine, which is undesirable.
Dupont further teaches a ‘reverse routability check’ to address some of the issues associated with the replay_type possibility. ‘Reverse routability check’ generally refers to an approach in which the machine at the other end of the secure connection (i.e., the end machine other than the one with the changing IP address) may request the moving end machine to identify itself, and the moving end machine may send a response with an appropriate identifier.
Unfortunately, reverse routability check type of approaches also may not be robust enough in avoiding the diversion of packets to unknown third machines. For example, when the unknown third machine (after sending the address update request) receives a reverse routability check, the contents of the check may be forwarded to the machine which has moved to a new address. The machine with the new address may respond back with an appropriate response for the reverse routability check, which can be forwarded to the machine at the other end of the secure connection. The response may be accepted by the machine at the other end, and packets may thereafter be diverted to the unknown third machine.
What is therefore needed is a method and apparatus to reliably continue a secure connection when the address of a machine at one end of the connection changes.
In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.